refa(devcontainer): rework to use mise for fast switching#2948
Conversation
solnic
changed the title
solnic
force-pushed
the
refa/rework-devcontainer
branch
from
e22e805 to
41504fa
Compare
solnic
force-pushed
the
refa/rework-devcontainer
branch
from
048daa5 to
d6cd2e6
Compare
solnic
force-pushed
the
refa/rework-devcontainer
branch
from
9d2348d to
b6e5dbd
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| if "$MISE_BIN" list ruby 2>/dev/null | grep -qF "${RUBY_VERSION}"; then | ||
| echo "✅ ruby@${RUBY_VERSION} already installed, skipping download." | ||
| else | ||
| echo "📦 Installing ruby@${RUBY_VERSION} (precompiled)..." | ||
| "$MISE_BIN" install "ruby@${RUBY_VERSION}" |
There was a problem hiding this comment.
Bug: The check for an existing Ruby installation using mise list ruby | grep -qF "latest" always fails in local dev, causing mise install to run on every container start.
Severity: MEDIUM
Suggested Fix
Resolve the "latest" alias to a concrete version number before checking if it's installed. For example, run mise resolve ruby@latest to get the version string, store it in a variable, and then use that variable for both the grep check and the mise install command.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: .devcontainer/run#L43-L47
Potential issue: In local development environments where `RUBY_VERSION` is unset, it
defaults to `"latest"`. The script checks for an existing installation using `mise list
ruby | grep -qF "latest"`. This check always fails because `mise list` outputs the
resolved concrete version number (e.g., `4.0.3`), not the alias `"latest"`.
Consequently, `mise install ruby@latest` is executed on every container start, requiring
a network connection. Because the script uses `set -euo pipefail`, any network
interruption will cause the container to fail to start, even if the correct Ruby version
is already installed.
Did we get this right? 👍 / 👎 to inform future reviews.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 9c27785. Configure here.
| # Install headless Chromium via Playwright (includes all system dependencies). | ||
| # Symlink the binary into ~/.local/bin which is already on PATH. | ||
| RUN /home/sentry/.local/share/mise/shims/npx playwright install chromium --with-deps | ||
| RUN bash -c 'ln -sf /home/sentry/.cache/ms-playwright/chromium-*/chrome-linux/chrome /home/sentry/.local/bin/chromium' |
There was a problem hiding this comment.
Chromium symlink broken on x86_64 Linux builds
High Severity
The symlink hardcodes chrome-linux/chrome, but Playwright ≥1.57 on Linux x64 installs Chromium under chrome-linux64/chrome. Since CI uses ubuntu-latest (x86_64) and npx playwright install chromium fetches the latest version, the glob resolves to a non-existent subdirectory, creating a broken symlink. File.exist? in spec_helper.rb then returns false, so options.binary is never set, and Selenium cannot locate the Chrome binary — breaking e2e tests on x64 runners. The path chrome-linux/chrome only works on ARM64, which appears to be where the author tested (PR description shows aarch64-linux).
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 9c27785. Configure here.
2 participants
This rework comes with 3 nice improvements:
1. Mise for fast switching between modern ruby versions (including jruby)
The image by default ships with the latest ruby (4.0.3 at the moment), and then switching to older rubies is super easy:
All that in less than 20s.
For legacy Rubies, we still use dedicated dev container builds, no way around this.
2. Improved e2e spec setup in CI
Supports running against 4.x and 3.x rubies and uses pre-built images from the
build_imagesworkflow. We also no longer depend onforemanfor running e2e test apps, and instead we just usemisescripts.3. Versioned dev container images with workflow manual trigger enabled
Our build images workflow publishes versioned images based on
.devcontainer/VERSIONso it's easier to maintain this setup now. Especially when a topic branch is used to make some tweaks, like this very PR/branch.